home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.modula2
- Path: rugeyes.chinalake.navy.mil!Peter_Eyes_Eiserloh
- From: Peter P. Eiserloh <Peter_Eyes_Eiserloh@WSSAGW.chinalake.navy.mil>
- Subject: Re: Modula2 for C programmers?
- Content-Type: text/plain; charset=ISO-8859-1
- Message-ID: <DM49Ht.Iwp@avalon.chinalake.navy.mil>
- X-Xxmessage-Id: <AD36734B080121C9@rugeyes.chinalake.navy.mil>
- X-Xxdate: Thu, 1 Feb 1996 20:40:27 GMT
- Sender: usenet@avalon.chinalake.navy.mil (NAWS news admin)
- Content-Transfer-Encoding: 8bit
- Organization: Naval Air Warfare Center - Weapons Division
- X-Newsreader: Nuntius 2.0.4_68K
- References: <DLMz95.9r4@cix.compulink.co.uk> <DM2KB6.983@nyongwa.montreal.qc.ca>
- Mime-Version: 1.0
- Date: Thu, 1 Feb 1996 21:39:28 GMT
-
- Hi,
-
- Real world examples abound where access to low level bit operations
- are required. My particular application requires analysis of data
- recorded from an embedded system. These analysis applications are
- usually run on only one type of computer, but it would be nice if
- the source code were portable.
-
- Type transfer functions (CASTS) to and from BITSETs (and custom sets)
- are a low level operation that is required for many situations. Bit
- twiddling is required for many situations.
-
- Examples which come to mind are (1) converting a MIL-STD-1750 floating
- point single precision number into IEEE format (2) a number is stored
- in a bitfield within a 16 bit word, and (3) a fixed point number where
- the least significant bit has a value other than one.
-
- These all require a knowledge of how the data is represented in the
- computer. Given the various methods with which this data can be
- represented causes these to be non-portable
-
- In article <DM2KB6.983@nyongwa.montreal.qc.ca> Michel De Rosa,
- aliath@nyongwa.montreal.qc.ca writes:
- >Mark Morgan Lloyd (mark_tbu@cix.compulink.co.uk) wrote:
- >: > neither does it do any sort of interpretation of the bits,
- >: > i.e. it's a straight copy of the bitmap, if you will..
- >:
- >: Watch it! I've argued this one in the past with TopSpeed, who IIRC under
- >: certain circumstances _do_ apply transformations.
- >
- >Really? They do that?... hmmmm do you have any cases, where they do this,
- >so i can avoid 'debugging' time.. ;{)
- >
- >I really don't see what aspect of this 'feature', they felt needed changing,
- >PIM is really quite clear on this... I would have argued the point too..
-
- Type transfer functions (CASTs) do not simply copy the bits, but rather
- they have some very simple sematics.
-
- [1: Type transfer between same sizes]
-
- Straight copy of the bits.
-
- [2: Type transfer from long to short]
-
- This should simply truncate off the most significant bits, leaving
- the least significant N bits. This may actually modify bits form
- the original data. This must not cause a run-time error.
-
- [3: Type transfer from short to long]
-
- Signed numbers need help. An cast from an INTEGER to a LONGINT
- (or possibly SHORTINT -> INTEGER, and SHORTINT -> LONGINT)
- would extend the sign bit (assuming twos complement) into the
- upper bits of the LONGINT. This does not modify any of the
- original bits though.
-
- All other transfers should be treated as unsigned, in particular
- CHARs.
-
- In addition, type transer fucntions are restricted to only simple types
- (ie. not records or arrays), but do allow bitsets, and custom sets if
- they fit within a word or longword. Some compilers allow very large
- sizes of sets (ie. 256 elements for SET OF CHAR), but this is very
- non-standard.
-
- NOTE: all comments are made without knowledge of the ISO-xxxx standard.
- If any of my comments contradict this standard please inform me.
-
- Peter
- -----
-